System, method and computer program product for virtual patching

ABSTRACT

A system, method, and computer program product are provided for virtual patching. Initially, information associated with at least one vulnerability of a computer application is collected. Further, at least one host interface is identified that is capable of being used to access the vulnerability. In use, data sent to the at least one host interface is analyzed to determine whether the data is unwanted, based on the information.

FIELD OF THE INVENTION

The present invention relates to computer security software, and moreparticularly to patching security vulnerabilities.

BACKGROUND

Due to the ever-increasing amounts of unwanted data computer systemsmust be protected against, software updates for security programs havebecome a growing necessity. Specifically, unwanted data such as viruses,worms, Trojan horses, spyware, etc. is constantly being developed byattackers to intrude and sometimes even destroy computer systems. Forexample, the results of unwanted data has ranged from mild interferencewith a program, such as the display of an unwanted political message ina dialog box, to the complete destruction of data on a hard drive, andeven the theft of personal information.

Many security programs have been created in order to provide theprotection required by modern computer systems. For example, firewalls,intrusion detection software, scanners, etc. have been used alone and incombination in order to best guard computer vulnerabilities against alltypes of unwanted data. However, with increasing amounts of unwanteddata constantly being developed by attackers to circumvent such securityprograms, continuous updates have become necessary for providing ampleprotection.

One type of update commonly provided by manufacturers of securityprograms includes patching. Patching is a method by which softwareupdates for security programs are provided to computer systems utilizingsuch security programs, in order to protect the computer systems againstnewly discovered vulnerabilities. These patches generally includeexecutable programs (or data that may be used by installation programs)that are run on the computer systems utilizing the security programs.

Due to the large number of updates needed to keep up with constantlydiscovered newfound computer system vulnerabilities, patching can becomequite cumbersome. In particular, patching generally requires that allcomputer systems running the associated security program individuallyexecute, or install, the patch. This results in an extremelytime-consuming process. First, once a vulnerability is discovered, apatch must be created to protect the vulnerability. Then, the patch mustbe tested to make sure that it, in fact, protects the vulnerability.Finally, the patch must be distributed to all pertinent computer systemswhich must each install the patch individually and then reboot in orderfor the patch to operate.

For large corporations utilizing security software, the patching processmay require the distribution and execution of a single patch tothousands of computers. In view of the vast number of patches that arecreated almost daily, this process becomes very inefficient. Inaddition, a network of computers, such as within a company or even overthe Internet, will most likely be at risk for quite some time since fullprotection against the vulnerability is not provided until all computersystems install the patch. Furthermore, patches generally build on oneanother such that a latest patch requires all previous patches to havebeen installed. This may cause problems in and of itself if users ofcomputer systems are not diligent in installing all patches.

To overcome the problems associated with patching, intrusion preventionsystems have been created that employ behavioral blocking techniques. Inthese types of systems, continuous patching is not needed sincesignatures for matching specific processes and data are not used.However, since intrusion prevention systems only rely on recognizedbehaviors, protection is limited such that many vulnerabilities gounprotected.

Due to the inefficiencies of the foregoing patching and intrusionprevention methods, a more efficient method is needed which is capableof addressing vulnerability issues more quickly and effectively. Thereis thus a need for overcoming these and/or other problems associatedwith the prior art.

SUMMARY

A system, method, and computer program product are provided for virtualpatching. Initially, information associated with at least onevulnerability of a computer application is collected. Further, at leastone host interface is identified that is capable of being used to accessthe vulnerability. In use, data sent to the at least one host interfaceis analyzed to determine whether the data is unwanted, based on theinformation.

In one embodiment, the information may be collected from a softwarepatch. In addition, an event may be initiated if the data is determinedto be unwanted. Such event may include preventing the data fromaccessing the at least one host interface. Optionally, the event mayinclude creating a software exception. As another option, the event mayinclude suspending a thread executing the data. Further, the event mayinclude terminating execution of a process associated with the data.

In another embodiment, the information may include public information.As an option, the information may be collected utilizing black boxtesting. The information may also be collected utilizing binarydifferentiation. Additionally, the at least one host interface may beidentified utilizing a debugger. In another aspect, the at least onehost interface may be identified utilizing a static analysis. Still yet,a closest host interface may be identified and only data sent to theclosest host interface may be analyzed, when a plurality of the hostinterfaces is identified.

In yet another embodiment, the collecting, identifying and analyzing maybe capable of being disabled. Furthermore, the collecting may includefiltering the information and classifying the information. Specifically,the filtering may optionally include identifying a vulnerability name,severity level and/or affected platform. As another option, theidentifying may include reproducing the vulnerability and determining aroot cause of the vulnerability. In addition, a detection algorithm mayalso be created for utilization in detecting subsequent unwanted data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network architecture, in accordance with oneembodiment.

FIG. 2 shows a representative hardware environment that may beassociated with the data server computers arid/or end user computers ofFIG. 1, in accordance with one embodiment.

FIG. 3 shows a method for virtual patching, in accordance with oneembodiment.

FIG. 4 shows a method for virtual patching, in accordance with anotherembodiment.

DETAILED DESCRIPTION

FIG. 1 illustrates a network architecture 100, in accordance with oneembodiment. As shown, a plurality of networks 102 is provided. In thecontext of the present network architecture 100, the networks 102 mayeach take any form including, but not limited to a local area network(LAN), a wireless network, a wide area network (WAN) such as theInternet, etc.

Coupled to the networks 102 are data server computers 104 which arecapable of communicating over the networks 102. Also coupled to thenetworks 102 and the data server computers 104 is a plurality of enduser computers 106. Such client computers 106 may each include a desktopcomputer, lap-top computer, mobile phone, hand-held computer, anycomponent of a computer, and/or any other type of logic. In order tofacilitate communication among the networks 102, at least one gateway orrouter 108 is optionally coupled therebetween.

It should be noted that any of the foregoing computers in the presentnetwork architecture 100, as well as any other unillustrated hardwareand/or software, may be equipped with various security system features.For example, the various data server computers 104 and/or end usercomputers 106 may be equipped with security system hardware and/orsoftware for protecting the various computers on any of the networks 102against unwanted data. More information regarding optional functionalityand optional architectural components associated with such feature willnow be set forth for illustrative purposes.

FIG. 2 shows a representative hardware environment that may beassociated with the data server computers 104 and/or end user computers106 of FIG. 1, in accordance with one embodiment. Such figureillustrates a typical hardware configuration of a workstation inaccordance with one embodiment having a central processing unit 210,such as a microprocessor, and a number of other units interconnected viaa system bus 212.

The workstation shown in FIG. 2 includes a Random Access Memory (RAM)214, Read Only Memory (ROM) 216, an I/O adapter 218 for connectingperipheral devices such as disk storage units 220 to the bus 212, a userinterface adapter 222 for connecting a keyboard 224, a mouse 226, aspeaker 228, a microphone 232, and/or other user interface devices suchas a touch screen (not shown) to the bus 212, communication adapter 234for connecting the workstation to a communication network 235 (e.g., adata processing network) and a display adapter 236 for connecting thebus 212 to a display device 238.

The workstation may have resident thereon any desired operating system.It will be appreciated that an embodiment may also be implemented onplatforms and operating systems other than those mentioned. Oneembodiment may be written using JAVA, C, and/or C++ language, or otherprogramming languages, along with an object oriented programmingmethodology. Object oriented programming (OOP) has become increasinglyused to develop complex applications.

Our course, the various embodiments set forth herein may be implementedutilizing hardware, software, or any desired combination thereof. Forthat matter, any type of logic may be utilized which is capable ofimplementing the various functionality set forth herein.

FIG. 3 shows a method 300 for virtual patching, in accordance with oneembodiment. As an option, the present method 300 may be implemented inthe context of the architecture and environment of FIGS. 1 and/or 2. Ofcourse, however, the method 300 may be carried out in any desiredenvironment.

Initially, information associated with at least one vulnerability of acomputer application is collected, as shown in operation 302. Forexample, the information may be publicly available information collectedfrom public resources (e.g. MICROSOFT Monthly Security announcements,full-disclosure mailing lists, etc.) that describe the vulnerability(e.g. name, source, process utilized for exploitation, codepath/function utilized for exploitation, severity level, affectedplatform(s), vulnerable products, external references to exploit code,documentation on the computer application, etc.).

As another option, the information may be collected from a softwarepatch associated with a vulnerability in a computer application. In oneexample, the information may be collected from the software patchutilizing black box testing. Black box testing may be utilized when theknown information associated with the vulnerability includes a knownexploit and a known result associated with the exploit. In general,black box testing may be used for collecting information about avulnerability when there is no known information about theinner-workings of the vulnerability. In such a situation, the knownexploit may be researched utilizing debugging methodologies in order tocollect detailed information about the vulnerability. Just by way ofexample, the IDA PRO DISASSEMBLER and DEBUGGER made by DATARESCUE, Inc.may be utilized for collecting the information by way of a debugger asdescribed hereinabove.

In another example, binary differentiation may be utilized forcollecting the vulnerability information from the software patch. Binarydifferentiation includes the enumeration of all functions within twofiles: the first file being the software patch and the second file beingthe latest version of the computer application without the patch. Forexample, the latest version of the computer application may include theoriginal computer application with all patches except the present patchfrom which information is being collected.

Once the functions for each are enumerated, two code trees are createdsuch that one code tree is created for the enumerated functions of eachfile. The two code trees are then compared so that the content of eachfunction in one tree is matched with content of a function in the othertree. In this way, the functions of each file can be mapped and onlyinformation concerning functions that have changed (or are new) in thepatched file are collected. Just by way of example, such binarydifferentiation may be accomplished utilizing the SABRE BinDiff productby SABRE Security.

As an option, the vulnerability information collected in operation 302may further include filtering the information and/or classifying theinformation. Examples of such filtering and classifying will bedescribed in more detail with respect to FIG. 4.

After the information is collected in operation 302, at least one hostinterface that is capable of being used to access the vulnerability isidentified, as shown in operation 304. The host interface may be anytype of function or interface that serves as a gateway or access pointto the vulnerability (e.g. vulnerable code in the computer application,etc.). As an option, the host interface may be identified utilizing adebugger. For example, a break may be placed in vulnerable codeidentified in the information collected in operation 302. Then, the codemay be traced to identify the location in the code creating thevulnerability.

As another option, the host interface may be identified utilizing astatic analysis to find the execution flow in the vulnerableapplication. For example, if the vulnerability is located within anexecutable file, the executable file may be run for identifying errormessages, creating error log files, etc. In addition, if no exploit isknown in association with the vulnerability, a debugger may be utilizedfor locating all code paths associated with functions leading to thevulnerable code.

Of course, it should be noted that any method may be utilized which iscapable of identifying at least one host interface for accessing thevulnerability. In some embodiments, a plurality of host interfaces maybe identified. In such a case, a closest host interface may beidentified in operation 304. The closest host interface may beidentified according to any number of criteria, such as a shortest codepath to the vulnerability, a code path previously utilized forexploiting the vulnerability, etc.

Furthermore, operation 304 may additionally include reproducing thevulnerability and/or determining a root cause of the vulnerability.Examples of reproducing the vulnerability and determining a root causeof the vulnerability will be described in more detail during referenceto FIG. 4. Once the root cause is determined, a vector of thevulnerability may be recorded. Optionally, the vector may be in the sameform as the object in which the vulnerability is located. For example,if the vulnerability is in the header of an image file, the vector maybe a file. Further, if the vulnerability is in a network service, thevector may be a network, etc. Table 1 illustrates various data thevector may include.

TABLE 1 Location of the vulnerable code   Name of executable   Shortdescription of location in vulnerable product in   which vulnerableexecutable is implemented Possible input vectors that are capable ofexploiting the vulnerable code. Root cause information

The root cause determined with respect to operation 304 may also beutilized for creating a detection algorithm for detecting subsequentunwanted data. Such detection algorithm will be described in furtherdetail during reference to FIG. 4. After at least one host interface isidentified in operation 304, data sent to the interface is analyzed inorder to determine whether the data is unwanted, as shown in operation306. In the context of the present description, the unwanted data mayinclude any malicious data, such as viruses, worms, Trojan horses,spyware, etc., and/or any other data and/or code that is unwanted. Withthe knowledge of the location of the vulnerable code from operations 302and 304, it may be determined whether the data is unwanted. For example,the data may be determined to be unwanted if it attempts to access thevulnerable code.

In an embodiment where a plurality of host interfaces are identified inoperation 304, as described above, only the closest host interface maybe analyzed in operation 306. Of course, any number of the hostinterfaces may be analyzed in operation 306, as desired.

As an option, the collecting, identifying and analyzing of operations302-306 may be disabled at any time. In addition, if it is determined inoperation 306 that the data is unwanted, an event may be initiated. Suchevent may include, but is not limited to preventing the data fromaccessing the at least one host interface, creating a softwareexception, suspending a thread executing the data, terminating executionof a process associated with the data, and/or any other type of desiredevent.

Furthermore, the information collected in operations 302-306 may beutilized for implementing a system that intercepts calls made to theinterface identified in operation 304 and further invokes a function tovalidate such calls each time they are made. Such a system may beincluded in any intrusion prevention or detection system. In addition,the system may report attempts to exploit vulnerabilities. In this way,it is not necessary for a patch to be distributed and installed at eachcomputer utilizing the software application, while up-to-date protectionmay still be provided that efficiently addresses newfoundvulnerabilities. Of course, physical patching may be used in combinationwith the aforementioned virtual patching, as desired.

More illustrative information will now be set forth regarding variousoptional architectures and features with which the foregoing method 300may or may not be implemented, per the desires of the user. It should bestrongly noted that the following information is set forth forillustrative purposes and should not be construed as limiting in anymanner. Any of the following features may be optionally incorporatedwith or without the exclusion of other features described.

FIG. 4 shows a method for virtual patching, in accordance with anotherembodiment. As an option, the present method 400 may be implemented inthe context of the architecture and environment of FIGS. 1-3. Of course,however, the method 400 may be carried out in any desired environment.

Initially, information associated with at least one vulnerability of acomputer application may be collected, as shown in operation 402. Suchinformation may be collected in any manner, such as, for example, thatdescribed with respect to operation 302 of FIG. 3. Informationassociated with the vulnerability may then be filtered and classified,as in operation 404.

Filtering the information collected in operation 404 may includeidentifying a vulnerability name, severity level and/or affectedplatform of the vulnerability. Of course, any other such informationassociated with the information collection in operation 402 may beidentified by way of a filter. In this way, only information pertinentto the vulnerability and/or the cause of the vulnerability is availableafter collection. As another option, the collected information ofoperation 402 may be utilized for classifying the vulnerability. Suchclassification may be made according to a severity of the vulnerability,vulnerable products, etc.

At least one host interface that is capable of being used to access thevulnerability may then be identified, as indicated in operation 406.Such host interface may be identified in any desired manner. Oneoptional example may be that described with respect to operation 304 ofFIG. 3.

The vulnerability may then be reproduced, as illustrated in operation408. As described hereinabove, such vulnerability may be reproducedutilizing a debugger, by simply executing an executable file leading tothe vulnerability, or by any other mechanism capable of reproducing thevulnerability. A specific example of vulnerability reproduction mayinclude installing the operating system version and/or product versionrelated to the vulnerability, and utilizing the information collected inoperation 402 for exploiting the vulnerability.

A root cause analysis may then be carried out in order to determine theroot cause of the vulnerability, as in operation 410. A root cause ofthe vulnerability may be determined utilizing the identification of thevulnerable code, as described with respect to FIG. 3. Just by way ofexample, the root cause may be any function in code that provides accessto a computer system.

Then, the root cause may be utilized in creating a detection algorithm,as in operation 412. For example, such detection algorithm may includeany type of signature or may simply include a blueprint for creating anysuch signature, for use with a desired system [e.g. Host IntrusionPrevention System (HIPS), Network Intrusion Prevention System (NIPS),etc.]. Finally, as yet another option, all calls attempting to accessthe host interface may be intercepted and validated before being allowedto proceed via the host interface, as shown in operation 414. Thisoption may be included in any intrusion prevention or detection system.In addition, it may report attempts to exploit vulnerabilities.

Again, it is not necessary for a patch to be distributed and installedat each computer utilizing the software application, since thevulnerability is not required to be fixed in order to protect thecomputer system. Instead, known vulnerabilities are utilized forvalidating calls made to the vulnerable code. Therefore, up-to-dateprotection is provided which efficiently addresses newfoundvulnerabilities.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. For example, any of the network elements may employ any ofthe desired functionality set forth hereinabove. Thus, the breadth andscope of a preferred embodiment should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

1-21. (canceled)
 22. A method, comprising: identifying a host interfacethat is capable of being used to access a vulnerability of a computerapplication; recording a vector associated with a root cause of thevulnerability; intercepting a call attempting to access the hostinterface; and validating the call based on the root cause.
 23. Themethod of claim 22, further comprising creating a software exception ifdata associated with the call is unwanted.
 24. The method of claim 22,further comprising suspending a thread if data associated with the callis unwanted.
 25. The method of claim 22, further comprising terminatingexecution of a process associated with the call.
 26. The method of claim22, wherein the vector comprises a location of the vulnerability. 27.The method of claim 22, wherein the vector comprises input vectorscapable of exploiting the vulnerability.
 28. The method of claim 22,wherein the vector comprises information associated with the root cause.29. The method of claim 22, wherein the vector is recorded in a sameform as an object in which the vulnerability is located.
 30. A computerprogram product embodied on a non-transitory computer readable mediumfor performing operations, the operations comprising: identifying a hostinterface that is capable of being used to access a vulnerability of acomputer application; recording a vector associated with a root cause ofthe vulnerability; intercepting a call attempting to access the hostinterface; and validating the call based on the root cause.
 31. Thecomputer program product of claim 30, wherein the operations furthercomprise creating a software exception if data associated with the callis unwanted.
 32. The computer program product of claim 30, wherein theoperations further comprise suspending a thread if data associated withthe call is unwanted.
 33. The computer program product of claim 30,wherein the operations further comprise terminating execution of aprocess associated with the call.
 34. The computer program product ofclaim 30, wherein the vector comprises a location of the vulnerability.35. The computer program product of claim 30, wherein the vectorcomprises input vectors capable of exploiting the vulnerability.
 36. Thecomputer program product of claim 30, wherein the vector comprisesinformation associated with the root cause.
 37. The computer programproduct of claim 30, wherein the vector is recorded in a same form as anobject in which the vulnerability is located.
 38. A system, comprising:a processor configured for executing non-transitory instructions storedin a memory, wherein the system is configured for: identifying a hostinterface that is capable of being used to access a vulnerability of acomputer application; recording a vector associated with a root cause ofthe vulnerability; intercepting a call attempting to access the hostinterface; and validating the call based on the root cause.
 39. Thesystem of claim 38, wherein the vector comprises a location of thevulnerability.
 40. The system of claim 38, wherein the vector comprisesinput vectors capable of exploiting the vulnerability.
 41. The system ofclaim 38, wherein the vector comprises information associated with theroot cause.